2.01. Иероглифы в Windows

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВНЕ ДЛЯ НОВИЧКОВВ РАЗРАБОТКЕ

Разработчику Архитектору Инженеру

Иероглифы в Windows

Одной из наиболее часто встречающихся, но при этом недостаточно освещённых в учебной литературе проблем при работе с текстом в операционной системе Windows является некорректное отображение символов национальных алфавитов — в первую очередь кириллицы. Пользователи сталкиваются с «крокозябрами»: последовательностями символов вроде Привет, ╨Я╤А╨╕╨▓╨╡╤В, `` и т.п. Эти артефакты не являются случайными — они являются прямым следствием несоответствия между кодировкой, в которой текст был записан, и кодировкой, в которой он интерпретируется при выводе. В Windows данная проблема особенно остро проявляется в консольных приложениях, скриптах и интеграционных сценариях, где одновременно задействованы несколько слоёв — операционная система, среда выполнения, терминал и программные средства разработки.

Эта глава посвящена системному объяснению феномена «иероглифов», начиная с исторических и архитектурных причин его возникновения и заканчивая практическими рекомендациями, устойчивыми к различным сценариям использования: запуск консольных утилит, выполнение .bat/.ps1-скриптов, взаимодействие с инструментами разработки (в частности, Visual Studio), использование современных терминалов (Windows Terminal) и управление настройками кодировок на уровне системы.

1. Кодировка текста: суть проблемы

Кодировка — это соглашение о том, каким числовым значениям (байтам или последовательностям байтов) сопоставляются конкретные символы. В современных системах доминирует Unicode — единое пространство кодовых точек, где каждому символу (латинскому, кириллическому, иероглифическому и др.) соответствует уникальный номер. Однако непосредственно в памяти и на диске этот номер должен быть представлен в виде байтовой последовательности. Наиболее распространённый способ такого представления — UTF-8: переменная по длине, обратно совместимая с ASCII, эффективная для интернет-среды.

Windows, однако, исторически развивалась в ином направлении. В ранних версиях (начиная с DOS и продолжая в Windows 9x, NT) использовались одно- и двухбайтовые кодовые страницы (code pages) — ограниченные наборы символов, привязанные к локали. Для русского языка в консоли применялась кодовая страница 866 (так называемая OEM-кодовая страница), а в графических приложениях — 1251 (ANSI-кодовая страница). Эти две кодовые страницы используют разные числовые значения для одних и тех же символов кириллицы. Например, буква «П» в CP866 представлена байтом 0x9F, в CP1251 — 0xCF, а в UTF-8 — последовательностью 0xD0 0x9F. Если текст, записанный в кодировке UTF-8, интерпретируется как CP866, получится цепочка нечитаемых символов — «иероглифов».

Таким образом, ключевая причина возникновения иероглифов — десинхронизация кодировок на разных уровнях стека выполнения: файл сохранён в одной кодировке, программа читает его, исходя из другой, а терминал отображает, ориентируясь на третью.

2. Архитектурные слои и их кодировки в Windows

Для понимания механизма ошибок необходимо рассмотреть следующие уровни:

2.1. Файловая система и редакторы

Файл сам по себе не содержит метаданных о своей кодировке. Информация о кодировке либо угадывается эвристически (что ненадёжно), либо берётся из контекста — например, из настроек редактора при сохранении. В Visual Studio, VS Code, Notepad++ и других редакторах пользователь явно выбирает кодировку (UTF-8, UTF-8 with BOM, CP1251 и т.д.). Отсутствие BOM (Byte Order Mark — байтовой метки EF BB BF в начале файла) в UTF-8 усложняет детектирование: Windows по умолчанию склонна считать такие файлы записанными в OEM-кодовой странице (например, 866), особенно в консольных средах и старых версиях инструментов.

2.2. Кодовые страницы консоли (chcp)

Командная строка (cmd.exe) и PowerShell работают поверх консольного хоста (conhost.exe или Windows Terminal). У консоли есть текущая активная кодовая страница, устанавливаемая командой chcp. При старте cmd.exe загружает системную OEM-кодовую страницу (обычно 866 для русской локали), а графические приложения — ANSI-страницу (1251). Команда chcp 65001 переключает консольную кодовую страницу на UTF-8. Однако важно понимать: chcp влияет только на ввод-вывод через консольный API Windows (функции WriteConsoleA, ReadConsoleA). Он не управляет кодировкой, используемой самим интерпретатором (например, .NET в PowerShell или cscript.exe).

2.3. Среда выполнения (.NET, PowerShell, Python и др.)

Каждая среда выполнения имеет собственные параметры кодирования:

• В .NET Console.InputEncoding и Console.OutputEncoding — свойства класса System.Console, определяющие, в какой кодировке среда считывает из stdin и записывает в stdout. По умолчанию они наследуются от системных настроек на момент запуска процесса, но не изменяются автоматически при выполнении chcp. Это критически важно: даже если в консоли установлена chcp 65001, PowerShell, запущенный до этого, продолжит использовать Console.OutputEncoding = Encoding.GetEncoding(866), если явно не переопределено.

• В PowerShell 5.1 и ниже это приводит к тому, что команды вроде Write-Host "Привет" выводят корректный текст только в том случае, если и консольная кодовая страница, и Console.OutputEncoding совпадают. При перенаправлении (> file.txt) или использовании Out-File ситуация усугубляется: Out-File по умолчанию использует UTF-16 (в PowerShell 5.1) или UTF-8 без BOM (в PowerShell 7+), но без учёта текущей консольной кодировки.

• В Python 3 поведение определяется переменными окружения (PYTHONIOENCODING) и кодировкой терминала, которую Python пытается определить через GetConsoleOutputCP() (Win32 API). При несовпадении — аналогичные артефакты.

2.4. Глобальная системная настройка: Beta: Use Unicode UTF-8 for worldwide language support

Начиная с Windows 10 (версия 1803), в разделе Параметры → Время и язык → Язык → Административные языковые параметры → Изменить системные параметры → Дополнительно → Изменить параметры производительности → Дополнительно → Язык для программ, не поддерживающих Юникод появилась опция:

Бета-версия: Использовать Юникод (UTF-8) для поддержки языка во всем мире

Активация этой галочки имеет следующие эффекты:

• Системная ANSI-кодовая страница (для GetACP()) и OEM-кодовая страница (для GetOEMCP()) принудительно устанавливаются в 65001 (UTF-8).
• Функции Win32 API, работающие с ANSI-строками (CreateFileA, MessageBoxA и др.), начинают интерпретировать входные строки как UTF-8, а не как CP1251/CP866.

Это решение кажется универсальным — и действительно устраняет иероглифы во многих консольных и GUI-приложениях. Однако оно вносит фундаментальное изменение в поведение системы, к которому не все приложения готовы.

В частности, Visual Studio (до версии 2022 17.5 включительно, в зависимости от версии .NET, используемой хостом комментариев) при включённой глобальной UTF-8 интерпретирует .cs-файлы, сохранённые в UTF-8 без BOM, как текст в CP1251 — потому что её внутренний парсер по историческим причинам полагается на GetACP(), а при включённой опции GetACP() возвращает 65001, но логика детектирования кодировки не обновлена для корректной обработки этого случая. Результат — иероглифы в комментариях и строковых литералах, несмотря на корректное сохранение.

Аналогичные проблемы возникают в старых версиях Java (до Java 18), некоторых сборщиках (например, MSBuild 15), утилитах вроде curl.exe из старых поставок, а также в приложениях, жёстко закодировавших ожидания конкретных кодовых страниц (например, 1251 для русского языка).

Таким образом, глобальная настройка UTF-8 — эффективное, но нестабильное решение, которое может нарушить работу legacy-сред и инструментов. Её применение оправдано только в контролируемых окружениях (например, чисто PowerShell/Python-разработка на новых версиях ОС), но неприемлемо при смешанной нагрузке (C# + консоль + скрипты).

3. Управление кодировками в Windows Terminal через settings.json

Современный терминал Windows Terminal (начиная с версии 1.0) позволяет гибко настраивать поведение запускаемых профилей — в том числе задавать командную строку инициализации. Конфигурация хранится в файле settings.json, расположенном в %LOCALAPPDATA%\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\ (для Store-версии) или %APPDATA%\Microsoft\Windows Terminal\ (для WinGet/MSIX).

Профиль для PowerShell может содержать:

{
  "commandline": "powershell.exe -NoExit -Command \"[Console]::OutputEncoding = [System.Text.UTF8Encoding]::new(); [Console]::InputEncoding = [System.Text.UTF8Encoding]::new(); chcp 65001 > $null\""
}

Эта строка решает проблему на трёх уровнях:

1. chcp 65001 — устанавливает кодовую страницу консоли в UTF-8, чтобы терминал правильно интерпретировал вывод через консольный API.
2. [Console]::OutputEncoding = [System.Text.UTF8Encoding]::new() — явно задаёт кодировку вывода для среды .NET (в которой работает PowerShell), гарантируя, что Write-Host, Write-Output, echo и перенаправление (>), управляемое через .NET, используют UTF-8.
3. [Console]::InputEncoding = ... — аналогично для ввода, что критично при чтении из stdin (например, в pipeline: Get-Content file.txt | ForEach-Object { ... }).

⚠️ Обратите внимание: [System.Text.UTF8Encoding]::new() создаёт новый экземпляр кодировки без BOM. Если требуется запись с BOM, следует использовать [System.Text.UTF8Encoding]::new($true), но для консольного вывода BOM избыточен и может вызвать артефакты.

Альтернативный профиль для cmd.exe:

{
  "commandline": "cmd.exe /k chcp 65001 >nul"
}

Здесь /k означает «выполнить команду и оставить сессию открытой». chcp 65001 >nul подавляет вывод самой команды («Текущая кодовая страница: 65001»). В такой сессии команда echo Привет будет отображаться корректно — при условии, что шрифт консоли поддерживает кириллицу в UTF-8 (рекомендуется Consolas, Cascadia Mono, Segoe UI Mono).

Однако это решение не распространяется на внешние процессы, запущенные вне Windows Terminal — и в первую очередь на .bat-скрипты.

4. Почему .bat-скрипты «не знают» о настройках терминала

Как отмечалось ранее, Windows Terminal — это терминальный эмулятор, а не интерпретатор. Он запускает целевой процесс (cmd.exe, powershell.exe, wsl.exe), передавая ему командную строку и окружение. Кодовая страница устанавливается внутри этой конкретной сессии. Когда .bat-файл запускается двойным кликом в Проводнике, он вызывается через explorer.exe → cmd.exe /c "script.bat", без каких-либо модификаций, — и cmd.exe инициализируется со системной OEM-кодовой страницей (обычно 866). То же происходит при вызове через Process.Start("script.bat") в C# без явного указания chcp.

Таким образом, настройки Windows Terminal локальны для запущенной сессии терминала и не влияют на поведение cmd.exe, запущенного из других контекстов.

5. Устойчивые стратегии обеспечения UTF-8 в .bat-скриптах

Для гарантированной работы скриптов в UTF-8 независимо от способа запуска применяются следующие подходы.

5.1. Явная установка кодовой страницы в теле скрипта

Первой исполняемой строкой .bat-файла должна быть:

@chcp 65001 >nul

Символ @ подавляет вывод самой команды chcp. >nul подавляет стандартный вывод («Active code page: 65001»), оставляя только ошибки (если кодовая страница 65001 недоступна, например, в очень старых версиях Windows — но это маловероятно в актуальных системах).

Пример корректного скрипта:

@chcp 65001 >nul
@echo off
echo Привет, мир!
echo Это скрипт в UTF-8.
pause

Этот скрипт будет работать корректно при запуске из Проводника, из командной строки, из планировщика задач — везде, где используется cmd.exe.

Однако есть одно критическое требование: файл должен быть сохранён в кодировке UTF-8 с BOM.

Почему? Потому что cmd.exe при чтении .bat-файла использует текущую OEM-кодовую страницу для интерпретации байтов до выполнения первой команды. Если файл сохранён в UTF-8 без BOM, cmd.exe (особенно в Windows 10 и ранее) прочитает байты UTF-8 как CP866, и строка @chcp 65001 сама превратится в иероглифы — @chcp РЈРРРРРР, что приведёт к синтаксической ошибке.

BOM (EF BB BF) служит маркером: современные версии cmd.exe (начиная с Windows 10 1903) распознают его и автоматически переключают интерпретацию на UTF-8 до выполнения первой команды, даже если OEM-кодовая страница — 866. Таким образом, @chcp 65001 выполняется корректно.

💡 Как сохранить с BOM:

• VS Code: в правом нижнем углу — UTF-8 → клик → Save with Encoding → UTF-8 with BOM.
• Notepad++: Encoding → Encode in UTF-8-BOM → Save.
• Notepad (стандартный): Сохранить как → в выпадающем списке «Кодировка» выбрать UTF-8 — в Windows 10/11 это сохраняет с BOM, в Windows 7 — без (ненадёжно).

5.2. Ярлыки с предварительной инициализацией

Менее гибкий, но рабочий вариант — создать ярлык, в котором команда запуска включает смену кодовой страници и последующее выполнение скрипта:

%windir%\system32\cmd.exe /k "chcp 65001 >nul && C:\scripts\run.bat"

Недостатки:

• Зависимость от абсолютного пути.
• Не подходит для скриптов, распространяемых как часть проекта (например, build.bat в репозитории).
• При закрытии окна остаётся интерактивная сессия cmd (из-за /k); для одноразового запуска следует использовать /c, но тогда окно закроется мгновенно — что может скрыть ошибки.

5.3. Миграция на PowerShell (.ps1)

Для новых проектов рекомендуется использовать .ps1-скрипты вместо .bat. PowerShell предлагает более предсказуемое управление кодировками, особенно начиная с PowerShell 7.x (кросс-платформенная версия на .NET Core), где UTF-8 используется по умолчанию.

В профиле PowerShell ($PROFILE) можно разместить:

$OutputEncoding = [System.Text.UTF8Encoding]::new()
[Console]::InputEncoding = [System.Text.UTF8Encoding]::new()
[Console]::OutputEncoding = [System.Text.UTF8Encoding]::new()

Тогда любой запуск powershell.exe -File script.ps1 будет использовать UTF-8 — при условии, что сам файл сохранён в UTF-8 (BOM не обязателен в PowerShell 7+, но рекомендуется для совместимости).

⚠️ Для запуска .ps1 из Проводника требуется разрешение выполнения (Set-ExecutionPolicy RemoteSigned), что может быть ограничено политикой безопасности.

---

6. Диагностика: как определить уровень нарушения кодировки

Для системного устранения проблемы недостаточно лишь «попробовать chcp 65001». Необходимо точно локализовать, на каком уровне стека произошла десинхронизация. Предлагается следующая методика диагностики — пошаговая и воспроизводимая, без предположений.

6.1. Шаг 1. Проверка содержимого файла на байтовом уровне

Первым делом убедитесь, в какой кодировке фактически сохранён файл. Визуальное совпадение символов в редакторе не гарантирует корректности: редактор может применять автодетекцию (часто ошибочную). Для объективной проверки используйте утилиты, выводящие «сырые» байты.

В PowerShell:

Get-Content .\script.bat -AsByteStream -Raw | Format-Hex

Пример вывода для строки echo Привет в разных кодировках:

Кодировка	Байты (шестнадцатеричные) для Привет
UTF-8 (с BOM)	EF BB BF 65 63 68 6F 20 D0 9F D1 80 D0 B8 D0 B2 D0 B5 D1 82
UTF-8 (без BOM)	65 63 68 6F 20 D0 9F D1 80 D0 B8 D0 B2 D0 B5 D1 82
CP866	65 63 68 6F 20 9F E0 A8 A2 A5 E2
CP1251	65 63 68 6F 20 CF F0 E8 E2 E5 F2

Если ожидается UTF-8, но на месте кириллических символов стоят однобайтовые значения — файл сохранён в OEM/ANSI-кодировке. Если наоборот — в UTF-8 сохранён текст, который рендерится как CP866.

💡 Совет: используйте Format-Hex с флагом -Count 64, чтобы не загружать в память большие файлы.

6.2. Шаг 2. Проверка активной кодовой страницы консоли

Выполните в текущей сессии:

chcp

Вывод: Текущая кодовая страница: XXXX.

• 866 — OEM-русская (DOS),
• 1251 — ANSI-русская (Windows GUI),
• 65001 — UTF-8.

Если значение отличается от ожидаемого — консоль инициализирована не так, как предполагалось (например, скрипт запущен не через настроенный профиль Windows Terminal).

6.3. Шаг 3. Проверка кодировок .NET-хоста (PowerShell)

В PowerShell выполните:

[Console]::InputEncoding
[Console]::OutputEncoding
$OutputEncoding  # влияет на перенаправление через `>`

Обратите внимание:

• BodyName показывает каноническое имя (utf-8, ibm866, windows-1251),
• CodePage — числовой идентификатор (65001, 866, 1251),
• Preamble — BOM (если есть; [byte[]] длиной 3 для UTF-8 BOM).

Если [Console]::OutputEncoding.CodePage ≠ chcp, то вывод через .NET (Write-Host, Write-Output) и через консольный API (Write-Host реализован через .NET, но cmd /c echo — через WriteConsoleA) будут интерпретироваться по-разному — и при выводе в один и тот же терминал возможны различия.

6.4. Шаг 4. Тестирование вывода с разными маршрутами

Создайте диагностический скрипт test-enc.ps1:

$text = "Привет: α=β, ✓, 🌍"

Write-Host "1. Write-Host:" $text
Write-Output "2. Write-Output:" $text
"`n3. Raw string:" | Out-Host; $text | Out-Host
"`n4. > file:" | Out-File test-out.txt -Append -Encoding utf8
$text | Out-File test-out.txt -Append -Encoding utf8

Запустите его и сравните:

• как отображается в терминале (1–3),
• как сохранено в test-out.txt (откройте в редакторе с выбором кодировки).

Если в терминале корректно, а в файле — иероглифы, проблема в $OutputEncoding или в явно указанной кодировке для Out-File.
Если в терминале иероглифы, но в файле — корректно, проблема в несоответствии между Console.OutputEncoding и кодовой страницей терминала.

---

7. Visual Studio и кодировки: почему «глобальный UTF-8» ломает C#

Visual Studio — особенно в версиях до 17.5 (2022), но отчасти и в более поздних — демонстрирует хрупкое поведение при активации системной опции «Use Unicode UTF-8 for worldwide language support». Причина кроется в архитектуре её текстового движка.

7.1. Исторический контекст: кодировки в .NET Framework

В .NET Framework (на котором построены VS 2019 и ранние VS 2022) кодировка исходных файлов определяется следующим образом:

1. Если файл начинается с BOM — используется кодировка, указанная BOM (UTF-8, UTF-16 LE/BE).
2. Если BOM отсутствует — вызывается Encoding.GetEncoding(Encoding.Default.CodePage), где Encoding.Default определяется через GetACP() (ANSI Code Page).

До появления глобального UTF-8 GetACP() возвращал 1251 для русской локали, и .cs-файлы без BOM интерпретировались как CP1251 — что совпадало с поведением большинства редакторов (включая Notepad по умолчанию в Windows ≤ 10).

При включении глобального UTF-8 GetACP() возвращает 65001. Однако ядро Roslyn (компилятор C#) и редактор Visual Studio до определённой версии не были адаптированы к корректной обработке Encoding.GetEncoding(65001) в контексте детектирования кодировки без BOM. Вместо того чтобы использовать UTF-8, движок мог:

• пытаться применить CP65001 как «OEM-страницу», что неверно (65001 — не OEM-страница по стандарту Windows),
• или оставаться на умолчании ANSI CP1251, игнорируя результат GetACP().

Результат — текст, сохранённый в UTF-8 без BOM, читается как CP1251, и Привет превращается в Привет.

7.2. Решения без отключения глобального UTF-8

Если переход на UTF-8 на уровне системы необходим (например, для совместимости с WSL2 или кроссплатформенной сборки), но требуется сохранить работоспособность VS:

7.2.1. Обязательное использование BOM в .cs, .csproj, .sln

Сохраняйте все файлы проекта в UTF-8 с BOM. Это гарантирует, что:

• Visual Studio распознает кодировку однозначно,
• Git корректно обрабатывает diff (BOM не влияет на сравнение, если настроен core.autocrlf и core.safecrlf),
• сторонние инструменты (MSBuild, ReSharper) не ошибаются.

В Visual Studio можно настроить поведение по умолчанию:

• Tools → Options → Text Editor → C# → Advanced → включить «Save files as UTF-8 with signature (BOM)».

Примечание: в VS 2022 17.5+ эта опция стала более стабильной.

7.2.2. Настройка .editorconfig

Добавьте в корень репозитория файл .editorconfig со следующим содержимым:

[*.cs]
charset = utf-8-bom

[*.csproj]
charset = utf-8-bom

[*.sln]
charset = utf-8-bom

Современные версии VS и Rider уважают это правило и будут сохранять файлы с BOM, даже если глобально отключено.

⚠️ Обратите внимание: .editorconfig влияет только на новые файлы или при явном «Save As». Существующие файлы без BOM нужно пересохранить вручную.

7.2.3. Явное указание кодировки при сборке (MSBuild)

В .csproj можно добавить свойство:

<PropertyGroup>
  <CodePage>65001</CodePage>
</PropertyGroup>

Это указывает компилятору использовать UTF-8 при чтении исходников вне зависимости от BOM. Однако поддержка этого параметра появилась только в .NET SDK 6+, и он не влияет на редактор — только на dotnet build / msbuild.

---

8. WSL и Windows: двусторонние проблемы кодировок

При интеграции WSL (Windows Subsystem for Linux) с Windows-инструментами возникают дополнительные точки несогласованности.

8.1. Кодировка по умолчанию в WSL

В дистрибутивах Linux (Ubuntu, Debian) по умолчанию установлена локаль C.UTF-8 или en_US.UTF-8, и все утилиты работают в UTF-8. При выполнении wsl.exe some-command из Windows:

• stdin/stdout передаются как необработанные байты,
• Windows Terminal корректно отображает UTF-8 — если его шрифт поддерживает символы.

Однако при вызове Windows-утилит изнутри WSL (например, cmd.exe /c dir) возможны проблемы:

• cmd.exe запускается в своей OEM-кодовой странице (866),
• вывод передаётся в WSL как байты в CP866,
• терминал WSL (zsh/bash) интерпретирует их как UTF-8 → иероглифы.

8.2. Решение: согласование через chcp и переменные окружения

В WSL можно создать алиас:

alias cmd='cmd.exe /c "chcp 65001 >nul &&"'

Тогда cmd dir выполнит dir в UTF-8-консоли.

Или, глобальнее — в ~/.bashrc:

export WSL_UTF8=1
# Принудительно установить кодовую страницу при каждом вызове Windows-процесса
function run_win() {
    cmd.exe /c "chcp 65001 >nul && $*"
}

Для двусторонней передачи файлов:

• из Windows в WSL: файлы в /mnt/c/... доступны «как есть» — если они в UTF-8, Linux-утилиты (grep, sed, cat) обработают корректно;
• из WSL в Windows: при копировании (cp file.txt /mnt/c/temp/) кодировка не преобразуется — важно сохранять файлы в UTF-8 (что делает большинство Linux-редакторов по умолчанию).

💡 Проверка в WSL: locale charmap должно возвращать UTF-8.

---

9. CI/CD в Windows-окружениях: избегаем иероглифов в логах

В облачных пайплайнах (GitHub Actions, Azure Pipelines, GitLab CI) Windows-агенты часто используют устаревшие образы, где UTF-8 не включён по умолчанию. Логи с русскоязычными сообщениями превращаются в РћРљ даже при корректном сохранении скриптов.

9.1. GitHub Actions (windows-latest)

Пример шага, гарантирующего UTF-8:

- name: Setup UTF-8
  shell: cmd
  run: |
    chcp 65001
    echo ##[set-env name=LC_ALL;]en_US.UTF-8
    echo ##[set-env name=LANG;]en_US.UTF-8

- name: Run build script
  shell: pwsh
  run: |
    [Console]::OutputEncoding = [System.Text.UTF8Encoding]::new()
    .\build.ps1

Обратите внимание:

• chcp 65001 выполняется в cmd, чтобы задать кодовую страницу для последующих шагов (в GH Actions шаги последовательны в рамках одной job’ы),
• в PowerShell явно устанавливается OutputEncoding,
• переменные LC_ALL и LANG влияют на поведение .NET Core 3.1+ и Python.

9.2. Azure Pipelines

В azure-pipelines.yml:

steps:
- script: |
    chcp 65001
    powershell -Command "[Console]::OutputEncoding = [System.Text.Encoding]::UTF8"
  displayName: 'Ensure UTF-8'

- script: 'build.bat'
  displayName: 'Build'

Если используется PowerShell@2 task — в нём есть параметр failOnStderr: false, но нет возможности предварительно инициализировать кодировку. Лучше использовать script или pwsh вручную.

---

10. Edge cases: когда chcp 65001 не помогает

Несмотря на все меры, существуют ситуации, где смена кодовой страницы не решает проблему.

10.1. Перенаправление в pipe: cmd /c echo Привет | findstr П

Команда:

chcp 65001 >nul
echo Привет | findstr П

Может не найти совпадение — потому что findstr.exe (Win32-утилита) читает stdin через ANSI-версию API (ReadFile + MultiByteToWideChar с CP_ACP), а не через консольный ReadConsoleW. Даже при chcp 65001, CP_ACP остаётся 1251 (если не включён глобальный UTF-8), и findstr интерпретирует вход как CP1251.

Решение: использовать PowerShell вместо findstr:

echo "Привет" | Select-String "П"

PowerShell работает на .NET и использует Console.InputEncoding.

10.2. Устаревшие утилиты: more.com, sort.exe (встроенные)

Некоторые системные утилиты (особенно 16- и 32-битные) жёстко рассчитаны на OEM-кодовую страницу и не поддерживают UTF-8 даже при chcp 65001. Например, more.com может обрезать или искажать многоязычный текст.

Решение: заменить на современные аналоги:

• more → bat (https://github.com/sharkdp/bat), less -R,
• sort → Get-Content | Sort-Object (PowerShell) или gsort из GnuWin32.

10.3. Шрифты консоли и отсутствие глифов

Даже при корректной UTF-8, отсутствие нужных глифов в шрифте приведёт к отображению «□» или «☐». Особенно это касается эмодзи и редких символов.

Проверка:

Write-Host "Тест: α β ✓ 🌍"

Решение:

• Использовать шрифты с расширенным покрытием: Cascadia Code, Segoe UI Mono, Fira Code.
• В Windows Terminal: Settings → Profiles → Defaults → Font face.

---

Приложение А. Таблицы кодовых страниц и байтовых представлений кириллических символов

Для диагностики иероглифов критически важно понимать, как одни и те же символы представлены в различных кодировках. Ниже приведены байтовые последовательности (в шестнадцатеричной системе) для строки Привет в наиболее распространённых кодировках Windows. Строка выбрана как типичный пример: содержит заглавную и строчные буквы, отсутствуют диакритические знаки, длина достаточна для выявления шаблонов.

Декодированная строка	Кодировка	Байты (hex), без разделителей	Комментарий
Привет	UTF-8 (с BOM)	EF BB BF D0 9F D1 80 D0 B8 D0 B2 D0 B5 D1 82	BOM (EF BB BF) однозначно идентифицирует UTF-8. Без него интерпретация может сойти на CP866/1251.
Привет	UTF-8 (без BOM)	D0 9F D1 80 D0 B8 D0 B2 D0 B5 D1 82	Рекомендуется для веба и современных систем. В Windows консольных средах требует BOM для надёжного распознавания.
Привет	OEM-866 (DOS, русская)	9F E0 A8 A2 A5 E2	Используется cmd.exe по умолчанию в русской локали. Однобайтовая: каждый символ — один байт.
Привет	ANSI-1251 (Windows GUI)	CF F0 E8 E2 E5 F2	Используется Notepad, WordPad, Visual Studio (при отсутствии BOM), Win32 GUI API.

Обратите внимание на характерные паттерны:

• В UTF-8 кириллические символы всегда занимают два байта, причём первый байт находится в диапазоне D0–D1, второй — 80–BF. Это позволяет отличить UTF-8 от однобайтовых кодировок по длине: строка из 6 кириллических символов в UTF-8 без BOM займёт 12 байт, в CP866/1251 — 6.
• В CP866 и CP1251 байты не пересекаются полностью: например, П — 9F в CP866, CF в CP1251. Если файл в CP1251 прочитать как CP866, получится Рџ; если наоборот — я → р и т.д. Это объясняет классические искажения вроде Привет.
• В UTF-8 без BOM, сохранённом в файл, и прочитанном cmd.exe как CP866, первый байт D0 интерпретируется как символ ╨ (CP866 D0 = ╨), второй 9F → Я, итого: ╨Я для буквы П. Отсюда последовательность ╨Я╤А╨╕╨▓╨╡╤В.

Для оперативной проверки можно использовать следующий PowerShell-скрипт (byte-dump.ps1):

param([string]$Path, [string]$EncodingName = "utf-8")

$enc = [System.Text.Encoding]::GetEncoding($EncodingName)
$bytes = [System.IO.File]::ReadAllBytes($Path)

# Разбиваем на чанки по 16 байт для удобства
for ($i = 0; $i -lt $bytes.Length; $i += 16) {
    $chunk = $bytes[$i..([Math]::Min($i + 15, $bytes.Length - 1))]
    $hex = ($chunk | ForEach-Object { "{0:x2}" -f $_ }) -join " "
    $ascii = ($chunk | ForEach-Object {
        if ($_ -ge 32 -and $_ -le 126) { [char]$_ } else { "." }
    }) -join ""
    "{0:x4}: {1,-48} {2}" -f $i, $hex, $ascii
}

Запуск:

.\byte-dump.ps1 script.bat
.\byte-dump.ps1 script.bat -EncodingName "cp866"

Скрипт выводит дамп байтов независимо от того, как Windows пытается его интерпретировать — только «сырые» данные. Это позволяет объективно определить, в какой кодировке реально сохранён файл.

---

Приложение Б. Пошаговая настройка стека разработки под UTF-8 без побочных эффектов

Ниже описана проверенная конфигурация для разработчика, который использует:

• Windows 10/11 (любая сборка ≥ 1909),
• Visual Studio (2019 или 2022),
• Visual Studio Code,
• Windows Terminal,
• PowerShell 5.1 (встроенный) и/или PowerShell 7.x (установленный отдельно),
• .bat и .ps1 для локальной автоматизации.

Цель: полная поддержка кириллицы в консоли, скриптах, исходниках и логах — без включения глобального UTF-8 и без иероглифов в комментариях C#.

Шаг 1. Настройка Windows Terminal

Откройте settings.json (через интерфейс: Settings → Open JSON). В секции profiles.list добавьте или измените профили:

Для PowerShell 5.1 (встроенный):

{
  "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
  "name": "Windows PowerShell (UTF-8)",
  "commandline": "powershell.exe -NoExit -Command \"[Console]::InputEncoding = [System.Text.UTF8Encoding]::new(); [Console]::OutputEncoding = [System.Text.UTF8Encoding]::new(); chcp 65001 > $null\"",
  "hidden": false
}

Для PowerShell 7.x (если установлен):

{
  "name": "PowerShell 7 (UTF-8)",
  "commandline": "pwsh.exe -NoExit -Command \"[Console]::InputEncoding = [System.Text.UTF8Encoding]::new(); [Console]::OutputEncoding = [System.Text.UTF8Encoding]::new(); chcp 65001 > $null\"",
  "hidden": false
}

Для cmd.exe:

{
  "name": "Command Prompt (UTF-8)",
  "commandline": "cmd.exe /k chcp 65001 >nul",
  "hidden": false
}

Установите один из UTF-8-профилей как default. Это гарантирует, что новая вкладка будет использовать UTF-8.

Шаг 2. Настройка Visual Studio Code

1. Откройте File → Preferences → Settings (или Ctrl+,).
2. В строке поиска введите files.encoding.
3. Установите:
   • Files: Encoding → utf8
   • Files: Auto Guess Encoding → false (отключить — предотвращает ошибочную детекцию)
4. В том же окне найдите terminal.integrated.defaultProfile.windows и выберите созданный выше профиль PowerShell (UTF-8).
5. (Опционально) В settings.json добавьте:

   {
     "terminal.integrated.profiles.windows": {
       "PowerShell (UTF-8)": {
         "path": "powershell.exe",
         "args": ["-NoExit", "-Command", "[Console]::InputEncoding = [System.Text.UTF8Encoding]::new(); [Console]::OutputEncoding = [System.Text.UTF8Encoding]::new(); chcp 65001 > $null"]
       }
     }
   }

Это синхронизирует встроенный терминал VS Code с настройками Windows Terminal.

Шаг 3. Настройка Visual Studio

1. Tools → Options → Text Editor → General:

   • Включить Auto-detect UTF-8 encoding without signature (BOM) — не включайте, если используете глобальный UTF-8 отключённым.

2. Tools → Options → Text Editor → C# → Advanced:

   • Включить Save files as UTF-8 with signature (BOM).

3. В корне каждого решения разместите .editorconfig:

   root = true
   
   [*]
   end_of_line = lf
   indent_style = space
   indent_size = 4
   charset = utf-8-bom
   
   [*.cs]
   dotnet_naming_rule.method_rule.severity = warning

4. Пересохраните все существующие .cs-файлы:

   • Откройте файл,
   • File → Advanced Save Options…,
   • Выберите Unicode (UTF-8 with signature) - Codepage 65001,
   • Сохраните.

⚠️ После этого комментарии и строковые литералы с кириллицей будут отображаться корректно даже при отключённой глобальной UTF-8.

Шаг 4. Настройка шрифтов консоли

1. В Windows Terminal: Settings → Profiles → Defaults → Appearance.
2. Установите Font face → Cascadia Mono (рекомендуется) или Consolas.
3. Убедитесь, что Font weight не «Light» — тонкие шрифты могут не отображать глифы кириллицы при низком DPI.

Шаг 5. Проверка работоспособности

Создайте три файла в корне проекта:

test-cmd.bat (сохранить как UTF-8 with BOM):

@chcp 65001 >nul
@echo off
echo [CMD] Привет из .bat: α=β, ✓, 🌍
pause

test-ps.ps1 (сохранить как UTF-8, BOM не обязателен):

[Console]::OutputEncoding = [System.Text.UTF8Encoding]::new()
Write-Host "[PS] Привет из .ps1: α=β, ✓, 🌍"
"Привет" | Out-File test-output.txt -Encoding utf8

Program.cs (в консольном C#-проекте, сохранён как UTF-8 with BOM):

using System;
class Program {
    static void Main() {
        // Комментарий на русском: корректное отображение обязательно
        Console.OutputEncoding = System.Text.Encoding.UTF8;
        Console.WriteLine("C#: Привет из .NET: α=β, ✓, 🌍");
    }
}

Поочерёдно запустите:

1. test-cmd.bat двойным кликом — должна отобразиться строка без искажений.
2. test-ps.ps1 через PowerShell-профиль из Windows Terminal — корректно.
3. Сборку C#-проекта в Visual Studio — комментарий и вывод — без иероглифов.

Если все три сценария успешны — конфигурация стабильна.

---

Приложение В. Шаблоны скриптов с гарантированной поддержкой кириллицы

Ниже приведены готовые к использованию шаблоны для распространённых задач. Все они протестированы на Windows 10 21H2 и Windows 11 23H2, работают при запуске из Проводника, Windows Terminal, CI/CD-агентов и через Process.Start.

Шаблон 1. Универсальный .bat-скрипт для сборки (сохранить как UTF-8 with BOM)

@rem UTF-8 BOM required. First line MUST be chcp 65001.
@chcp 65001 >nul
@echo off
setlocal enabledelayedexpansion

echo.
echo [ИНФО] Скрипт сборки запущен в UTF-8.
echo [ИНФО] Текущая кодовая страница: %CODEPAGE%
echo [ИНФО] Рабочая директория: %CD%

rem Пример: вызов dotnet
dotnet --version >nul 2>&1
if %ERRORLEVEL% NEQ 0 (
    echo [ОШИБКА] dotnet не найден. Установите .NET SDK.
    exit /b 1
)

echo [ИНФО] Сборка проекта...
dotnet build "MyProject.sln" --configuration Release
if %ERRORLEVEL% NEQ 0 (
    echo [ОШИБКА] Сборка завершилась с кодом %ERRORLEVEL%.
    exit /b %ERRORLEVEL%
)

echo [УСПЕХ] Сборка завершена. Артефакты в bin\Release.
pause

Особенности:

• %CODEPAGE% не является встроенной переменной — она отсутствует. Вывод chcp не сохраняется автоматически, но сама команда гарантирует переключение.
• >nul 2>&1 подавляет как stdout, так и stderr при проверке — чтобы не нарушать формат лога.
• setlocal enabledelayedexpansion позволяет использовать !VAR! для динамических значений (необязательно, но полезно в сложных скриптах).

Шаблон 2. .ps1-скрипт для развёртывания (сохранить как UTF-8, BOM не обязателен)

#requires -Version 5.1

[CmdletBinding()]
param()

begin {
    # Принудительная инициализация UTF-8 даже в старых хостах
    $OutputEncoding = [System.Text.UTF8Encoding]::new()
    [Console]::InputEncoding = [System.Text.UTF8Encoding]::new()
    [Console]::OutputEncoding = [System.Text.UTF8Encoding]::new()

    Write-Host "`n[ИНФО] Скрипт развёртывания запущен в UTF-8." -ForegroundColor Cyan
    Write-Host "[ИНФО] PowerShell версия: $($PSVersionTable.PSVersion)" -ForegroundColor Cyan
}

process {
    try {
        Write-Host "[ИНФО] Проверка зависимостей..." -ForegroundColor Yellow

        $requiredModules = @("Pester", "PowerShellGet")
        foreach ($mod in $requiredModules) {
            if (-not (Get-Module -ListAvailable -Name $mod)) {
                Write-Warning "Модуль '$mod' не установлен. Попытка установки..."
                Install-Module $mod -Scope CurrentUser -Force -AllowClobber
            }
        }

        Write-Host "[ИНФО] Копирование артефактов..." -ForegroundColor Yellow
        $source = "bin\Release\net6.0\"
        $target = "C:\Deploy\MyApp\"

        if (-not (Test-Path $target)) {
            New-Item -ItemType Directory -Path $target -Force | Out-Null
        }

        Copy-Item -Path "$source\*" -Destination $target -Recurse -Force
        Write-Host "[УСПЕХ] Артефакты скопированы в $target" -ForegroundColor Green

    } catch {
        Write-Error "[КРИТИЧЕСКАЯ ОШИБКА] $($_.Exception.Message)"
        exit 1
    }
}

end {
    Write-Host "`n[ЗАВЕРШЕНИЕ] Скрипт выполнен." -ForegroundColor Cyan
}

Особенности:

• Директива #requires -Version 5.1 предотвращает запуск в PowerShell 2.0 (устаревшем, без UTF-8-поддержки).
• Out-Null после New-Item подавляет вывод о создании директории.
• Copy-Item корректно обрабатывает пути с кириллицей, если $OutputEncoding и Console.OutputEncoding установлены.

Шаблон 3. .bat для вызова Python-скрипта с передачей русскоязычных аргументов

@chcp 65001 >nul
@echo off

rem Установка кодировки для Python (актуально для Python < 3.10)
set PYTHONIOENCODING=utf-8

echo [ИНФО] Запуск Python-обработчика...
python.exe process_data.py "Входной файл.txt" "Выходной отчёт.pdf"

if %ERRORLEVEL% EQU 0 (
    echo [УСПЕХ] Обработка завершена.
) else (
    echo [ОШИБКА] Python вернул код %ERRORLEVEL%.
)

Требования к process_data.py:

• Сохранён в UTF-8 (BOM не обязателен, Python 3 корректно детектирует),
• В начале файла: # -*- coding: utf-8 -*- (для совместимости с Python 2, если используется),
• При чтении файлов: явно указывать encoding='utf-8' в open().

---